<html>
<head><meta charset="utf-8"><title>dealloc and layout · t-libs/wg-allocators · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/index.html">t-libs/wg-allocators</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html">dealloc and layout</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="200554081"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200554081" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200554081">(Jun 11 2020 at 14:47)</a>:</h4>
<p>Hi. I wrote a blog post about why I think <code>dealloc</code> has a flawed API (specifically taking a <code>Layout</code> argument). <code>AllocRef</code> inherits the same flaws, too. <a href="https://shift.click/blog/on-dealloc/">https://shift.click/blog/on-dealloc/</a></p>
<p>The summary of my argument is that: The prior <code>Layout</code> is rarely needed for dealloc/realloc in the underlying allocators, and is easily shimmed when it is. Requiring the layout complicates unsafe code, and introduces a completely new source of undefined behavior (IMO any time that happens it really needs to justify itself, rather than the inverse). It also prevents certain things that rust code might reasonably want to do.</p>
<p>That said, I know I've probably missed the boat here. I did look around though, and was not really able to find discussions on it at all (I probably would not have shared this post if I were able to).  It pretty clearly a design wart to me, and always makes me sweat when I'm unable to use identical code for computing layouts in alloc &amp; dealloc. That said, I can also tell there's been a lot of work spent formally defining what this parameter means (in terms of "fit"ting), and people get attached to things that get that kind of attention... So yeah IDK. Anyway, better shared than not probably.</p>



<a name="200567484"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200567484" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200567484">(Jun 11 2020 at 16:18)</a>:</h4>
<p>I agree that passing the Layout to dealloc is probably a poor design.</p>



<a name="200583016"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200583016" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200583016">(Jun 11 2020 at 18:05)</a>:</h4>
<p>from the RFC: <a href="https://github.com/pnkfelix/rfcs/blob/kind-allocator-api/text/0000-kinds-of-allocators.md#why-not-just-freeptr-for-deallocation">https://github.com/pnkfelix/rfcs/blob/kind-allocator-api/text/0000-kinds-of-allocators.md#why-not-just-freeptr-for-deallocation</a></p>



<a name="200583211"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200583211" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200583211">(Jun 11 2020 at 18:06)</a>:</h4>
<p>basically (from my point of view): jemalloc provided a dealloc method that took the layout info, and that avoided a tiny bit of overhead</p>



<a name="200589646"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200589646" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200589646">(Jun 11 2020 at 18:56)</a>:</h4>
<p>Please go ahead and demonstrate how to make <code>dealloc</code> in the global allocator on Windows work without the <code>Layout</code> parameter.</p>



<a name="200589727"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200589727" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200589727">(Jun 11 2020 at 18:57)</a>:</h4>
<p><a href="https://github.com/rust-lang/rust/blob/50c0192c64241d723066add22c53d472e2b9cba9/src/libstd/sys/windows/alloc.rs#L41-L51">https://github.com/rust-lang/rust/blob/50c0192c64241d723066add22c53d472e2b9cba9/src/libstd/sys/windows/alloc.rs#L41-L51</a></p>



<a name="200589729"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200589729" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200589729">(Jun 11 2020 at 18:57)</a>:</h4>
<p><span class="user-mention" data-user-id="125267">@Peter Rabbit</span> does the approach i listed at the bottom there not work?</p>



<a name="200589755"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200589755" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200589755">(Jun 11 2020 at 18:57)</a>:</h4>
<p>it should</p>



<a name="200589989"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200589989" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200589989">(Jun 11 2020 at 18:59)</a>:</h4>
<p>That does have the unfortunate consequence of making all allocations using that system bigger, and your code as written also does not work when the alignment is higher than the size of <code>AllocInfo</code>.</p>



<a name="200590708"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200590708" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200590708">(Jun 11 2020 at 19:05)</a>:</h4>
<p><code>let result_ptr = orig_ptr.add(offset);</code> does not preserve the alignment requirements of the allocation.</p>



<a name="200597727"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200597727" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200597727">(Jun 11 2020 at 19:58)</a>:</h4>
<p>Basically the rationale is that in 99% of cases (Box and Vec) the language already knows what the allocation size is, so it is redundant to have the allocator keep track of it too.</p>



<a name="200604760"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200604760" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200604760">(Jun 11 2020 at 20:54)</a>:</h4>
<p><span class="user-mention" data-user-id="125267">@Peter Rabbit</span> the alignment being correct is the point of <code>Layout::extend</code>, which I use: <a href="https://doc.rust-lang.org/nightly/std/alloc/struct.Layout.html#method.extend">https://doc.rust-lang.org/nightly/std/alloc/struct.Layout.html#method.extend</a></p>



<a name="200605539"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200605539" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200605539">(Jun 11 2020 at 21:01)</a>:</h4>
<p><code>Layout::extend</code> is the correct way to grow a layout, but it introduces several runtime checks and should be avoided when possible. As already mentioned in most cases the size is known at compile time but the compiler isn't necessarily able to optimize out <code>extend</code>. Also this slows down compile times and always require more space to be allocated than needed. Especially as aligned extending requires additional space to fulfill all alignments (size (usize), align(usize), data)</p>



<a name="200605916"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200605916" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200605916">(Jun 11 2020 at 21:04)</a>:</h4>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> <a href="#narrow/stream/197181-t-libs.2Fwg-allocators/topic/dealloc.20and.20layout/near/200604760">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="125267">Peter Rabbit</span> the alignment being correct is the point of <code>Layout::extend</code>, which I use: <a href="https://doc.rust-lang.org/nightly/std/alloc/struct.Layout.html#method.extend">https://doc.rust-lang.org/nightly/std/alloc/struct.Layout.html#method.extend</a></p>
</blockquote>
<p>Ah I see. In that case what it is doing is similar to what the Windows system allocator already does for overaligned allocations. So your proposed method <em>does</em> work when you specifically want an allocator that lets you forget what layout you used originally. It's just a bad idea to use as a global allocator due to the extra space overhead incurred on every single allocation, given that 99.9% of the time the layout information is encoded in the type system and trivially recomputed at drop time.</p>



<a name="200605967"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200605967" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200605967">(Jun 11 2020 at 21:04)</a>:</h4>
<p>Sure, an API only taking a pointer on <code>dealloc</code> is more simple, but inefficient. As allocators is a very low level API, I'm strongly against removing <code>Layout</code> from <code>dealloc</code></p>



<a name="200607036"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200607036" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200607036">(Jun 11 2020 at 21:13)</a>:</h4>
<p>It's inefficient for the allocators that don't already store it. A lot of them do, (most IME). From a performance standpoint, the current API prevents code from being able take advantage of optimizations that are possible by not having to provide the exact layout -- for example, being able to reuse an allocation rather than perform a dealloc and alloc pair.</p>



<a name="200607445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200607445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200607445">(Jun 11 2020 at 21:16)</a>:</h4>
<p>It like the only real benefit is slightly improved performance with a few allocators (yes, including the system allocator on windows, but IIRC this has other reasons that users who care about allocation perf are likely to want to switch in practice). That doesn't feel like enough to justify it.</p>



<a name="200607537"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200607537" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200607537">(Jun 11 2020 at 21:17)</a>:</h4>
<p>But, that said I didn't really expect to convince anybody here. I don't really enjoy arguing (which is why I don't participate much in lang design), but felt I should make my point.</p>



<a name="200610420"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200610420" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200610420">(Jun 11 2020 at 21:40)</a>:</h4>
<p>What if we added an API to allocators which embedded the layout in allocations specifically for use cases where the layout can't be tracked, but it would be specialized for allocators that don't <em>need</em> the layout on drop to not store extra data. That way it would not affect the 99.9% use case, and when it was used it would be efficient on allocators that support layout free dealloc.</p>



<a name="200612622"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200612622" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200612622">(Jun 11 2020 at 22:00)</a>:</h4>
<p>How such an API would look like without some compiler magic?</p>



<a name="200612776"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/200612776" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Tim Diekmann <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#200612776">(Jun 11 2020 at 22:01)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> Thank you for writing this up, though!</p>



<a name="202384501"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202384501" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202384501">(Jun 30 2020 at 00:39)</a>:</h4>
<p>I think a new method could be added with a default implementation that would actually allocate space for Layout+the actual request, but different allocator implementations could override it to not have to do that, like how <code>GlobalAlloc::realloc</code> is provided but most allocators override it.  (And similarly a method could exist that would read through the pointer to get the layout by default and then deallocate that, with that overridden for the malloc/free-allocator.)</p>
<p>It's certainly true that most existing allocators store the size, but I assume that's largely due to them wanting to work with C.  From the peanut gallery, I'd definitely like Rust to be able to provide a platform to potentially make ones that are faster by not having to look up the size.</p>



<a name="202461026"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202461026" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202461026">(Jun 30 2020 at 16:30)</a>:</h4>
<p>I don't really think it's actually potentially faster to not store the size. It might be (very) slightly more memory efficient, but in practice I think you'll always have to store a size in most allocators, since you often want to have extra space available for some realloc requests. That is, the size you return might not be the size that was asked for. The <code>MemoryBlock</code> API even reflects this fact.</p>



<a name="202492859"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202492859" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Peter Rabbit <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202492859">(Jun 30 2020 at 20:49)</a>:</h4>
<p>For the Windows heap allocator it has nothing to do with not storing the size. In fact Windows stores the precise size down to the byte and will tell you if you ask. Rather the issue is it can't do allocations with an alignment greater than the default alignment. The only way to make that compatible with not needing the layout at free time is to overallocate <em>all</em> allocations to have space for the header that stores the actual pointer to free.</p>



<a name="202501456"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202501456" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202501456">(Jun 30 2020 at 22:08)</a>:</h4>
<p>That's exactly why I didn't mention the alignment. I was responding to the comment that "I'd definitely like Rust to be able to provide a platform to potentially make ones that are faster by not having to look up the size."</p>



<a name="202821389"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202821389" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202821389">(Jul 03 2020 at 16:41)</a>:</h4>
<p>I'd probably argue that the fact jemalloc offers <code>sdallocx</code> is a good argument for there being benefit in passing the size</p>



<a name="202821511"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202821511" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202821511">(Jul 03 2020 at 16:43)</a>:</h4>
<p>That's a real-world example of an allocator allowing (but not requiring) giving the allocation size on deallocation</p>



<a name="202821588"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/197181-t-libs/wg-allocators/topic/dealloc%20and%20layout/near/202821588" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Christopher Durham <a href="https://rust-lang.github.io/zulip_archive/stream/197181-t-libs/wg-allocators/topic/dealloc.20and.20layout.html#202821588">(Jul 03 2020 at 16:44)</a>:</h4>
<p>Maybe the "only" benefit in general is less allocated size, but when that's for every single allocation, that has a significant impact on performance due to cache locality, memory pressure, and related factors</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>